System and method for efficient integration of government administrative and program systems

ABSTRACT

A system and method includes an interoperability engine dynamically generating and updating an application database, a web-based portal in a computer communications network, and a baseline data schema from at least one of a data source and a supplemental data source comprising self-describing documents, and enabling interoperability among application systems. The application database dynamically generates a reporting database. The web-based portal provides access to the application systems via the application database and the reporting database. The self-describing documents may be hosted. An integration unit maps the application systems to the baseline data schema and facilitates transmission and messaging between the baseline data schema and the application systems.

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application is a divisional of application Ser. No.09/691,058, filed Oct. 19, 2000, allowed.

[0002] This application is based upon and claims priority of U.S.Provisional Application No. 60/230,938 filed on Sep. 13, 2000, and U.S.patent application Ser. No. 09/691,058, filed Oct. 19, 2000, thecontents being incorporated herein by reference.

BACKGROUND OF THE INVENTION

[0003] 1. Field of the Invention

[0004] The present invention is directed to a system designed to assistfederal government organizations in facilitating the integration andsharing of core administrative and program data among disparate butinter-related application systems via a web-based portal and a back-endinteroperability engine.

[0005] 2. Description of the Related Art

[0006] Federal organizations perform their operations using a fragmentedset of computer systems. Each computer system associated with aparticular federal organization addresses specific administrative needs,such as financial management, procurement, property management, assetsales, and grants management. Each computer system may further supportprogram specific activities specific to the federal organization'smission, for example, environmental permitting, patent applicationprocessing, or managing customer relationship for social services. Thefederal organization may build its computer system in-house, purchasecommercial-off-the-shelf products vendors, or implement a systemdeveloped by other federal organizations (e.g., the National Institutesof Health=s contractor past performance system). In addition, thefederal organization may desire or be required to use external publiclyaccessible systems such as FedBizOpps (formerly known as the ElectronicPosting System), the Central Contractor Registration (“CCR”), theFederal Procurement Data System (“FPDS”), or the Federal AcquisitionManagement Information System (proposed to replace FPDS).

[0007] Each system provides value to the corresponding federalorganization in automating the individual processes and functions forwhich they are designed. However, the functions of these systems oftenoverlap, or need to interoperate. Consider the simple example of buyinga desk. A procurement system generates the purchase order, but theprocurement process requires interoperability with several othersystems. For instance, the purchasing agent may desire to postsolicitation information to FedBizOpps to solicit bids. Further, as partof the procurement decision process, the purchasing agent is required toconsider the past performance of potential vendors, for example, byaccessing past performance systems such as the NIH past performancesystem. The purchasing agent may require additional detailed vendordata, which may be stored in a CCR system. Further, before an order isfinalized, the organization=s financial system needs to be polled toensure that funds are available in the budget for the purchase and toobligate money for the ensuing payment. The purchasing agent may alsoneed to report order data to FPDS. A property manager may also want totrack the newly purchased item as a fixed asset in a property managementsystem.

[0008] To date, federal organizations have had limited options toachieve system integration. The federal organizations may buildindividual interfaces between two systems to enable those two systems tocommunicate and then repeat the process for other systems. However, thisapproach may result in a confusing network of related but separatelydeveloped interfaces that pose a high risk of being out of synch. Somefederal organizations resort to re-keying the data into each system;however, this approach is labor intensive and repetitive.

[0009] In the late 1990s, Enterprise Resource Planning (“ERP”) systemswere implemented in an attempt to solve interoperability problems amongadministrative systems in federal organizations by providing a singleapplication that performs a variety of administrative functions, rangingfrom human resource management to financial management and procurement.However, the ERP system posed its own set of problems. For instance,switching to the ERP system required organizations to replace legacyapplications with a new system and encumbered major systemimplementation expenses and management issues.

[0010] Additionally, the ERP system capabilities in specific functions,such as procurement, often fell short of robust functionality offered bybest-of-breed products that were designed specifically to support thosefunctions, thereby forcing organizations to choose between achieving aminimum level of administrative integration at the expense of deepfunctional support. Furthermore, it is difficult for any single softwareapplication system to anticipate and support all of the federalorganization=s potential programmatic needs, as well as, administrativeneeds. Even though the ERP system may meet some needs, it still requiresa network of interfaces to other applications within the organization(e.g., program support systems and administrative systems not covered bythe ERP) and requires a network of interfaces to publicly ownedapplications such as CCR and FedBizOpps. Seamless integration andcommunication among the various application systems requires extensiveinfrastructure or middleware architecture.

[0011] Portal tools enable delivery of data to employees, customers andbusiness partners via a web-based interface. Yet, the portal tools needunderlying instructions regarding what data to share among businesspartners, and the rules within which that data should be shared (e.g.,read only, not visible, editable, deletable).

[0012] Enterprise Application Integration (“EAI”) products offer robusttools for such interoperability tasks as mapping one system to a defineddata schema and sending messages from one system to another. EAI toolsoften provide out-of-the-box, “no coding” adapters that integrate widelyused commercial off the shelf (“COTS”) products. While EAI tools providea platform that can facilitate interoperability and out-of-the-boxadapters may provide a good integration starting point, several factorsexist that require an additional layer of interoperability automation.For example, in many cases, federal organizations have built their owncustom systems for which no standard adapter schema for a COTS productexists.

[0013] Additionally, out-of-the-box adapters are typically designed anddeveloped for lowest-common-denominator data integration needs and forcorporate business processes, not for federal organizations. Althoughmuch can be leveraged from commercial adapters to create federaladapters, these adapters must be changed or rewritten to accommodatecore federal requirements (e.g., verifying funds availability before apurchase order is finalized). A federal interoperability tool is neededthat enables federal organizations to pull their disparate applicationsystems together and to base the interoperability and integration onrules established as both government-wide and organization-wide policy.

SUMMARY OF THE INVENTION

[0014] It is an object of the present invention to provide for a systemthat allows internal government systems (e.g., program systems includingcustomer relationship management, internal operations, andadministrative systems including finance, procurement, property, assetsales, and grants) and external government systems (e.g., FedBizOpps,CCR, FPDS or the Federal Acquisition Management Information System) tocommunicate and exchange messages and allows an end user to access theplurality of disparate legacy, current, and emerging governmentapplication systems from a point of entry web-based portal in a computercommunications network. Further, the present invention ensures thatinformation is accessed and used only in authorized ways and maintainsthe integrity, availability, and/or confidentiality of the information.

[0015] It is an object of the present invention to provide for a system,a method, and a computer readable storage medium providing users of afederal organization administrative and program processes a singleweb-based system interface from which to conduct all businesstransactions and exchanges of information. In particular, a data sourceincludes self-describing documents including data elements, definitionsof data elements, data element contents, data element characteristicsand business function interoperability rules for each data element inthe application systems. An interoperability engine processes thedefinitions and the interoperability rules and provides interoperabilityamong the application systems. A point of entry web-based portalconnected to the back-end interoperability engine provides access todisparate federal application systems.

[0016] In accordance with another object of the present invention, adata source is regularly surveyed and the interoperability engineanalyzes changes to the data source. The interoperability enginedynamically generates and/or updates a baseline data schema based onchanges to the data source. The invention applies the baseline dataschema in various ways to dynamically build and maintain a single pointof access to and interoperability among multiple external,administrative and programmatic systems, as follows.

[0017] The interoperability engine dynamically updates an applicationdatabase structure based on changes to the data source as defined in thebaseline data schema. The interoperability engine dynamically updatesthe web-based portal interface based on the changes to the data sourceas defined in the baseline data schema. The interoperability enginedynamically updates system interoperability among multiple external,administrative, and programmatic systems based on changes to the datasource as defined in the baseline data schema. An integration unit isassociated with the baseline data schema to facilitate mapping andmessaging of data among the external systems, administrative systems,programmatic systems, and the application database. The web portalprovides access to the application database, which interoperates withthe external, administrative, and programmatic systems via theintegration unit based on rules defined by the baseline data schema.

[0018] In accordance with another object of the present invention, asystem includes an interoperability engine dynamically generating apoint of access, an application database, and a baseline data schema andenabling interoperability among application systems.

[0019] In accordance with another aspect of the present invention, amethod including dynamically generating a point of access, anapplication database, and a baseline data schema, enablinginteroperability among application systems using the baseline dataschema, and providing access to the application systems via the point ofaccess using the application database.

[0020] In accordance with a further object of the present invention, acomputer readable storage medium controlling a computer and includingdynamically generating a point of access, an application database, and abaseline data schema, enabling interoperability among applicationsystems using the baseline data schema, and providing access to theapplication systems via the point of access using the applicationdatabase.

[0021] These together with other objects and advantages, which will besubsequently apparent, reside in the details of construction andoperation as more fully hereinafter described and claimed, referencebeing had to the accompanying drawings forming a part hereof, whereinlike numerals refer to like parts throughout.

BRIEF DESCRIPTION OF THE DRAWINGS

[0022]FIG. 1 is a diagram of a system architecture in accordance withthe present invention;

[0023]FIG. 2 is a diagram of a dynamic start-up process, in accordancewith the present invention;

[0024]FIG. 3 is a diagram of a dynamic system update, in accordance withthe present invention; and

[0025]FIG. 4 is a diagram of a process performed by an interoperabilityengine, in accordance with the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0026]FIG. 1 is a schematic diagram of an embodiment of a system 10including a Web portal 20 allowing multiple users, such as citizens 22,agency staff 24, and other government staff 26 to access most currentinformation from various application systems, such as federal governmentapplication systems (e.g., external systems 30, program systems 32, andadministrative systems 34). These application systems may be of varioustypes and use various languages and protocols, such as Java, XML, C++,Visual Basic, etc.

[0027] Connected to the Web portal 20 is a Web server (not shown) thatdelivers an HTML document, or “Web page,” to a Web browser (not shown)when requested. These browsers take a document formatted in HTML,generate its visual display, and perform any associated processing.Internet communications are mainly based upon Hypertext transportprotocol (“HTTP”), Common gateway interface (“CGI”), Internet inter ORBprotocol (“IIOP”), and Java database connectivity (“JDBC”). HTTP is themain communication mechanism among web browsers and servers.

[0028] A data source 36 is provided including one or moreself-describing documents. The self-describing documents of the datasource 36 are, for example, XML documents based on document tabledefinitions (“DTD”) that define terms and fields of a core set of dataelements for the external systems 30, program systems 32, andadministrative systems 34 and their interrelationships. The DTD acts asa translator defining the terms and fields to be later used tocommunicate with the external systems 30, program systems 32, andadministrative systems 34. Thus, the DTD in the self-describingdocuments of the data source 36 may include, for example, data elements,data element contents, data element characteristics, and datainteroperability rules that may be necessary to facilitate communicationand messaging among the external systems 30, program systems 32, andadministrative systems 34.

[0029] In an exemplary embodiment, the data elements may include datalabels such as quantity, price, unit, award date, and obligated amount.Data element characteristics include fields such as Required, Optional,Text, Numeric. Data interoperability rules include operation rules ofsystem 10. The system 10 operation rules include required edit checksamong other data elements, for instance, cross-data edits currentlyspecified in the FPDS Reporting Manual, instructions identifying, at ageneric level, the data elements that a particular data source requires(e.g., labels such as Property, Finance, Procurement, Supplier,Citizen), and instructions identifying the different external systems30, program systems 32, and administrative systems 34 that share dataelements. The self-describing documents of the data source 36 maycontain additional data definitions and data interoperabilityinstructions as necessary to define the system 10 requirements andoperating rules, for example, tags that specify the current date andversion of the data source 36 and/or tags that specify the current dateand version for each data element within the self-describing documentsof the data source 36 (i.e., DTD).

[0030] A supplemental data source 38, for example, may be incorporatedproviding policies and best practices and also including one or moreself-describing documents. Using the supplemental data source 38,federal organizations have the option to define organization-specificself-describing documents that add data element components to the system10 beyond those defined by the data source 36. The federal organizationsmay provide modifications or updates to the data element componentsidentified by the data source 36 as optional. These modifications wouldbe incorporated into the self-describing documents of the supplementaldata source 38 and would override the defining characteristics of thespecific component contained in the data source 36. Further,organizations may add components (e.g., organization-specific dataelements or interoperability requirements) in addition to the componentsalready provided for in the data source 36.

[0031] The self-describing documents of the data source 36 and/or of thesupplemental data source 38 include data elements, data elementcontents, data element characteristics, and data interoperability rulesfor each data element required by the federal organizations implementingsystem 10 such as those elements required by the external systems 30,program systems 32, and administrative systems 34. Further, theself-describing documents of the data source 36 and/or of thesupplemental data source 38 may be hosted. For example, theself-describing documents of the data source 36 and/or of thesupplemental data source 38 may be hosted at a site owned by aproprietary owner (e.g., American Management Systems, AMS), at a publicsite (e.g., the General Services Administration), or at an implementingorganization site (e.g., Department of Transportation, Department of theInterior, or any other commercial organization).

[0032] An interoperability engine 40 provides interoperability betweenappreciation systems such as legacy, current, and emerging governmentexternal systems 30, program systems 32, and administrative systems 34.The interoperability engine 40 is a data extraction, transformation, andtransportation tool developed using common programming language (e.g.,Java, XML, C++, Visual Basic, etc.). The interoperability engine 40 maybe a transaction server, an application server, a component server, or abusiness rule server. The basic abilities of the interoperability engine40 include scalability, adaptability, recoverability, and manageability.

[0033] The interoperability engine 40 dynamically generates aninteroperability baseline data schema based on the self-describingdocuments from the data source 36 and/or the supplemental data source38. Specifically, the interoperability engine 40 generates in real time,in an automated manner and without human intervention, the baseline dataschema. The baseline data schema is a computer medium, self-describingdocuments, or files, such as XML, which can be used for generating Webportals, generating databases, and defining adaptors used by EAI tools.In essence, the baseline data schema functions as a common denominatorto leverage and enable interoperability among various systems.

[0034] These various systems may be any type of system that need tointeroperate with other systems and may be in any given format. In anexemplary embodiment, the baseline data schema functions as a commondenominator to leverage an EAI tool 36, to be later discussed, tocommunicate to external systems 30, program systems 32, andadministrative systems 34. The data elements in the baseline data schemaare mapped in a format that the EAI tool 36 or any other type ofintegration tool well known in the art can recognize. For instance, theEAI tool 36 may accept a common format of XML documents that the EAItool 36 can import and can be used to map to the various externalsystems 30, program systems 32, and administrative systems 34. In oneembodiment, the interoperability engine 40 includes the Web server.Alternatively, the Web server may stand separate from theinteroperability engine 40 and connected to the Web portal 20.

[0035] The interoperability engine 40 further dynamically generates anapplication database 45. In turn, the application database 45dynamically generates a reporting database 50 (i.e., the applicationdatabase 45 generates on the fly the reporting database 50). Once again,dynamic generation may be accomplished by generating in real time or inan automated manner without human intervention. The application database45 and the reporting database 50 are database structures connected tothe Web portal 20. The application database 45 and the reportingdatabase 50 contain identical data elements as a baseline data schema ofan interoperability engine 40, to be later described, in a structureddesign. The application database 45 provides the user with read/writeaccess to the external systems 30, program systems 32, andadministrative systems 34. The reporting database 50 is a data mart or adata warehouse that allows the user to access information from theexternal systems 30, program systems 32, and administrative systems 34,for example, in a read only format.

[0036] The interoperability engine 40 analyzes the self-describingdocuments received from the data source 36 and/or the supplemental datasource 38, interprets the self-describing documents, and generates thebaseline data schema. The interoperability engine 40 builds the Webportal 20 based on the baseline data schema. The interoperability engine40 enables the user to access the external systems 30, program systems32, and administrative systems 34 via, for example, the Web portal 20 orany other means using the application database 45 and the reportingdatabase 50, and supports messaging and sharing of information among theexternal systems 30, program systems 32, and administrative systems 34.Thus, the interoperability engine 40 dynamically generates theapplication database 45, the reporting database 50 structure, and theWeb portal 20 by applying, for instance, COTS database, OLAP, and Webportal tools well known in the art.

[0037] Once a user logs in, the Web portal 20 allows the user to accessdata information and/or navigate through the external systems 30,program systems 32, and administrative systems 34. Furthermore, in theevent the user wishes to access a particular external system 30, programsystem 32, and administrative system 34, the external system 30, programsystem 32, and administrative system 34 is configured, for example, toperform a security clearance prior to allowing the user to access theinformation. As an alternative, the data source 36 and/or thesupplemental data source 38 might be configured, for example, toincorporate security constraints in accordance with predefined securityrequirements from the external, administrative, and program systems. Forexample, source documents that define unclassified systems such asfinance, procurement, or property, and that are hosted by a public site,may be posted with low levels of security. Whereas, source documentsthat define systems that support classified operations or that containproprietary source definitions, would be posted with high levels ofsecurity.

[0038] In another embodiment, the interoperability engine 40 isprogrammed, for example, to monitor security clearance. The system 10architecture might be implemented to ensure user security administrationand validation key management on the network. The security clearance canbe verified, for example, at the time the user attempts to access theparticular external system 30, program system 32, or administrativesystem 34. Further, the system 10 can be implemented, for example, wherein the event the user is allowed to access a particular external system30, program system 32, or administrative system 34 but requires toaccess information from another external system 30, program system 32,and administrative system 34, the interoperability engine 40 may promptthe user, via the Web portal 20, that further security clearance isrequired to access the information.

[0039] This integration of the invention with internal and externalsystems enables all business partners both, inside and outside theimplementing federal organization, to interact with each other and sharedata via the Web portal 20. Entries into the Web portal 20 triggerEAI-enabled sharing of data from the baseline data schema to therelevant internal and external systems. This interoperability enablesusers, from the Web portal 20, to interact with internal and externalsystems and perform business transactions (e.g., post requests forquotations, access established sources of vendor data, post procurementsynopsis and award notices).

[0040] Furthermore, the interoperability engine 40 may include, forinstance, mechanisms to dynamically survey the information in the datasource 36 and/or the supplemental data source 38 to determine if anychanges have occurred within the data source 36 and/or the supplementaldata source 38. For instance, the interoperability engine 40 woulddynamically survey the tags in the self-describing documents of the datasource 36 and/or of the supplemental data source 38 specifying thecurrent date and version of the data source 36 and/or supplemental datasource 38, and thereby trigger the dynamic system update, to bedescribed in FIG. 3. In the alternative, the interoperability engine 40would dynamically survey the tags in each data element in theself-describing documents of the data source 36 and/or of thesupplemental data source 38 to determine if the current date and/orversion have changed and thereby trigger the dynamic system update. Thesystem 10 may also provide a mechanism to trigger a survey of the datasource 36 and/or the supplemental data source 38 on demand. For example,the data source 36 and/or the supplemental data source 38 may have amaster version number data element that the invention surveys, comparesto the last version number, and determines whether a new version of thedata source 36 and/or the supplemental data source 38 has been posted.In another embodiment, the interoperability engine 40 may trigger thesurvey to the data source 36 and/or the supplemental data source 38.

[0041] If the version has changed, the interoperability engine 40dynamically initiates maintenance or update adjustments based on thedata contained in the self-describing documents of the data source 36and/or the supplemental data source 38. If the version has not changed,the interoperability engine 40 dynamically updates the applicationdatabase 45, the reporting database 50, the baseline data schema, andthe Web portal 20 to reflect the current version number along withcurrent date and time as the last version survey conducted.

[0042]FIG. 2 is a diagram of a dynamic start-up process 100. Atoperation 110, memories are cleared, initial flag conditions are set,etc., as is well known in the art. From operation 110, process 100proceeds to operation 120, where process 100 dynamically surveys andanalyzes data elements, data element contents, data elementcharacteristics, and data interoperability rules included in the datasource 36 and/or the supplemental data source 38 self-describingdocuments. From operation 120, process 100 proceeds to operation 130,where process 100 dynamically generates the application database 45structure. From operation 130, process 100 proceeds to operation 140,where process 100 dynamically generates the reporting database 50structure. As previously described, the application database 45 allowsthe user to read/write information from and to the external systems 30,program systems 32, and administrative systems 34 via the Web portal 20to the external systems 30, program systems 32, and administrativesystems 34. The reporting database 50 allows the user to readinformation only from the external systems 30, program systems 32, andadministrative systems 34 via the Web portal 20.

[0043] From operation 140, process 100 proceeds to operation 150, whereprocess 100 dynamically generates the user interface Web portal 20.Specifically, process 100 creates a Web portal 20 corresponding to eachexternal systems 30, program systems 32, and administrative systems 34based on the information provided by either the proprietary host orpublic host in the self-describing documents of the data source 36and/or of the supplemental data source 38. From operation 150, process100 proceeds to operation 160, where process 100 dynamically generatesthe baseline data schema. Process 100 analyzes the information in thedata source 36 and/or the supplemental data source 38, interprets theinformation, and maps the information into the baseline data schema.

[0044] From operation 160, process 100 proceeds to operation 170, whereprocess 100 associates the baseline data schema with the EAI tool 36.The baseline data schema serves as a common denominator to leverage theEAI tool 36, to enable the external systems 30, program systems 32, andadministrative systems 34 to share information, and to allow a user toaccess information from the external systems 30, program systems 32, andadministrative systems 34. From operation 170, process 100 proceeds tooperation 180, where the integration unit is applied to map the externalsystems 30, the program systems 32, and the administrative systems 34 tothe baseline data schema. From operation 180, process 100 proceeds tooperation 185, where the EAI tool 36 is applied facilitatingtransmission and messaging between the baseline data schema and theexternal systems 30, the program systems 32, and the administrativesystems 34. Furthermore, in the embodiment described herein andillustrated in FIG. 2, process 100 performs operations 130,140, 150, and160 sequentially. In the alternative, an ordinary person skilled in theart can appreciate that process 100 may perform operations 130,140, 150,and 160 concurrently. Further, an ordinary person skilled in the art canappreciate that process 100 may be triggered on demand.

[0045] This integration of the invention with administrative andprogrammatic systems enables all business partners within the federalorganizations to interact with each other and share data via the Webportal 20. As a result, any data entered via the portal is stored in theapplication database 45. Entries into the application database 45trigger the EAI tool 36 to allow data sharing from the applicationdatabase 45 to the relevant administrative and programmatic systems.This interoperability enables users via the Web portal 20 to interactwith stovepipe external systems 30, program systems 32, andadministrative systems 34 and share data (e.g., update related records,trigger related transactions, access/validate/verify historical relateddata on demand for improved decision making). Thus, once process 100migrates all the information contained in the external systems 30, theprogram systems 32, and the administrative systems 34 to the applicationdatabase 45, process 100 provides an implementing organization, theoption to shut down the systems 30, 32, 34.

[0046] Once process 100 is completed, the application database 45, thereporting database 50, the user interface, and the baseline data schemaare dynamically updated by regularly polling the data source 36 and/orthe supplemental data source 38 via a system update process 200. In oneembodiment, the interoperability engine 40 regularly triggers process200 to survey for changes in the data source 36 and/or the supplementaldata source 38. In an alternative embodiment, the intelligence toautomatically survey the data source 36 and/or the supplemental datasource 38 is built in the self-describing documents. In anotheralternative embodiment, process 200 is triggered to survey thedata,source 36 and/or the supplemental data source 38, on demand,through the proprietary host, the public host, the implementingorganization host or the Web portal 20. For illustrative purposes,process 200, hereinafter described, is triggered by the interoperabilityengine 40.

[0047] For new or changed components, the dynamic system update process200 illustrated in FIG. 3 is performed to update data element, dataelement contents, data element characteristics, and datainteroperability rules for each data element flagged as being new orchanged. FIG. 3 illustrates a dynamic system update where process 200begins at operation 210 where memories are cleared, initial flagconditions are set, etc., as is well known in the art. From operation210, process 200 proceeds to operation 220, where process 200dynamically scans the data source 36 and/or the supplemental data source38 self-describing documents for data-specific flags that identify newor changed data source 36 and/or the supplemental data source 38components. A new or changed component may constitute a variety ofdistinct adjustments to the self-describing documents of the data source36 and/or of the supplemental data source 38, such as, a new dataelement or a revised edit check for an existing data element. In analternative embodiment, process 200 surveys and compares a masterversion number with a last version number and determines whether a newversion of the data source 36 and/or the supplemental data source 38exists.

[0048] From operation 220, process 200 proceeds to operation 230, wherea determination is made whether changes occurred in the self-describingdocuments of the data source 36 and/or of the supplemental data source38. In the event that no changes are made to the self-describingdocuments of the data source 36 and/or of the supplemental data source38, process 200 proceeds to operation 240. At operation 240, process 200updates the time the survey on the self-describing documents of the datasource 36 and/or of the supplemental data source 38 is performed.However, if at operation 230, changes are made to the self-describingdocuments of the data source 36 and/or of the supplemental data source38, process 200 proceeds to operation 250. At operation 250, process 200dynamically updates changes to the characteristics of the data elementand updates changes to the associated relationships among data elementswithin the self-describing documents.

[0049] From operation 250, process 200 proceeds to operation 260, whereprocess 200 processes the changes to the data elements, data elementcontents, data element characteristics, and data interoperability rulesand updates therefrom the application database 45. Similarly, atoperation 280, process 200 dynamically updates the reporting database 50structure. From operation 280, process 200 proceeds to operation 290,where process 200 dynamically updates the Web portal 20. Specifically,process 200 updates (e.g., read, edit, delete) data elements viewed fromthe web-based portal.

[0050] From operation 290, process 200 proceeds to operation 300, whereprocess 200 surveys and analyzes the updated data source and/orsupplemental data source self-describing documents of the data source 36and/or of the supplemental data source 38 and dynamically updates thebaseline data schema. Process 200 analyzes the updated information inthe data source 36 and/or the supplemental data source 38, interpretsthe information and maps the information into a baseline data schema.

[0051] From operation 300, process 200 proceeds to operation 310, whereprocess 200 associates the baseline data schema with the EAI tool 36.Specifically, process 200 dynamically updates the data elements, dataelement contents, data element characteristics, and datainteroperability rules in the baseline data schema thereby dynamicallyupdating the baseline data schema to leverage the integration unit tocommunicate to the external systems 30, the program systems 32, and theadministrative systems 34. From operation 310, process 200 proceeds tooperation 320, where the integration unit is applied to map theapplication system data to the updated baseline data schema. Fromoperation 320, process 200 proceeds to operation 330, where theintegration unit is applied facilitating messaging among the externalsystems 30, program systems 32, administrative systems 34, and theapplication database 45.

[0052] Thus, process 200 dynamically updates the baseline data schemaand the application database 45 to identify the identifying versioninformation (e.g., version number, date) of the surveyed and analyzeddata source 36 and/or the supplemental data source 38. This versioninformation is constantly displayed to the user via the web interface(e.g., Certified current through FAC 2000-1 dated <date>. Last surveyed:<date and time last surveyed>).

[0053] Thus, process 200 allows efficient and effective upgrade processfor government external systems 30, program systems 32, andadministrative systems 34. Process 200 provides dynamic migration fromany given legacy system to contemporary technologies, withoutinterruption in functionality or data access. Furthermore, in theembodiment described herein and illustrated in FIG. 3, process 200performs operations 260, 280, 290, and 300 sequentially. In thealternative, an ordinary person skilled in the art can appreciate thatprocess 200 may perform operations 260, 280, 290, and 300 concurrently.In the alternative, process 200 may be triggered on demand.

[0054] Because the interoperability engine 40 dynamically updates thechanges to the self-describing documents of the data source 36 and/orsupplemental data source 38, the baseline data schema, the Web portal20, the application database 45, and the reporting database 50, thesystem update process 200 is effective and efficient. However, in thealternative, the interoperability engine 40 may also update the entirethe self-describing documents of the data source 36 and/or supplementaldata source 38, the baseline data schema, the Web portal 20, theapplication database 45, and the reporting database 50. Further, thesystem update process 200 allows the users accessing the externalsystems 30, the program systems 32, and the administrative systems 34information via the Web portal 20, to have accurate and most up-to-dateinformation.

[0055]FIG. 4 is a diagram of process 350 performed by theinteroperability engine 40. At operation 351, process 350 receives dataelements, data element contents, data element characteristics, and datainteroperability rules from the data source 36 and/or the supplementaldata source 38. From operation 351, process 350 proceeds to operation352, where a new table(s) are either created or updated in theapplication database 45 depending on whether the dynamic start-upprocess 100 is performed or if the dynamic system update process 200 isperformed. From operation 352, process 350 proceeds to operation 354,where new database field(s) are created/updated in the applicationdatabase 45 and, at operation 356, process 350 allocates space for newdata elements captured in the application database 45. From operation356, process 350 proceeds to operation 358, where any data elementcontent that resides in the data source 36 and/or supplemental datasource 38 is fed into the space allocated in the new table(s)/field(s)in the application database 45.

[0056] In an alternative embodiment, any organization in the public orprivate sector could use the invention to achieve interoperability amongmultiple, disparate external systems 30, program systems 32, andadministrative systems 34 and provide a single web-based interface forall business partners. They may control the system design by eitheraccepting a publicly held standard self-describing data source 36 and/orthe supplemental data source 38, or by building their own privately heldself-describing data source 36 and/or the supplemental data source 38.The invention could also include the development of proprietary AMSself-describing data structures that can be sold to members of specificindustries as an “out-of-the-box” data source 36 and/or the supplementaldata source 38 for implementing the invention. Furthermore, an ordinaryperson skilled in the art will appreciate that interoperability may beachieved using multiple data sources and/or supplemental data sources,multiple application and reporting databases, and multiple baseline dataschema, or multiple Web portals.

[0057] The above embodiments are described as using various languagesand protocols, such as Java, XML, C++, Visual Basic, etc. However, thepresent invention is not limited to these languages and protocols, andothers can be used.

[0058] The many features and advantages of the invention are apparentfrom the detailed specification and, thus, it is intended by theappended claims to cover all such features and advantages of theinvention which fall within the true spirit and scope of the invention.Further, since numerous modifications and changes will readily occur tothose skilled in the art, it is not desired to limit the invention tothe exact construction and operation illustrated and described, andaccordingly all suitable modifications and equivalents may be resortedto, falling within the scope of the invention.

What is claimed is:
 1. A computer readable storage medium controlling acomputer and comprising a process of surveying a data source;dynamically generating a point of access user interface, an applicationdatabase, a reporting database, a baseline data schema based on the datasource; enabling interoperability among the application systems usingthe baseline data schema; mapping the application systems to thebaseline data schema; and providing access to the application systemsvia the point of access using the application database and the reportingdatabase.
 2. The computer readable storage medium as recited in claim 1,wherein the surveying of the data source is initiated on demand.
 3. Thecomputer readable storage medium as recited in claim 1, wherein thesurveying of the data source is regularly initiated.
 4. A computerreadable storage medium controlling a computer and comprising a processof surveying a data source; capturing changes to the data source;dynamically updating a point of access user interface based on thechanges to the data source; dynamically updating an application databaseand a reporting database based on the changes to the data source;dynamically updating an interoperability engine baseline data schemabased on the changes to the data source; allocating space in theapplication database for the changes to the data source; applying anintegration unit mapping the application systems to the baseline dataschema; and providing access to the application systems via the point ofaccess using the application database and the reporting database.
 5. Thecomputer readable storage medium as recited in claim 4, wherein thesurveying of the data source is initiated on demand.
 6. The computerreadable storage medium as recited in claim 4, wherein the surveying ofthe data source is regularly initiated.